home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / GRAPHICS / @FALCON / VIEWERS / MPLAYER.230 / SLIDSHOW.DOC < prev   
Encoding:
Text File  |  1996-12-30  |  11.4 KB  |  317 lines
  1. M_PLAYER: SLIDE-SHOWS and MOVIE-MAKER section (Quick Time or GIF)
  2. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  3.  
  4. How to run a slideshow?
  5. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  6.     Just choose your batch file instead of an animation (please, keep
  7. BAT as the batch extension).
  8.  
  9. How to run a movie-maker?
  10. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  11.     It's the same as before, but the batch file must contain the line
  12. 'o=file_path' to know witch file to create. If you simply clic on 'Go!', it
  13. will act as a slide-show, to get the Mov-Creation, you must use the key
  14. 'Alt' while clicking on the 'Go!' button. Easy, no?
  15.     It's the type of images you give that will determine the type of
  16. movie created:
  17.     tga -> Quick Time movie with RLE16 compression (and sound)
  18.     img -> Quick Time movie with RLE8 compression (and sound)
  19.     gif -> Gif movie (no sound)
  20.  
  21. How to create a BATCH FILE for a SLIDESHOW?
  22. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  23.  
  24.     A batch file is a simple ascii text files that contains 3 parts:
  25.     - the identifier
  26.     - the header
  27.     - the datas
  28.  
  29.     Only the first line must start ont the leftmost row, for the
  30. others, spaces and tab to indent are allowed, there must be only one
  31. command per line, lines starting with ';' are considered as comments.
  32.     The size of the file is limited to 12488 bytes (I think it's
  33. enough...).
  34.  
  35.     The identifier
  36.     ╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  37.  
  38.     It must be on the first line, first character and is always:
  39.         M_PLAYER or m_player (or m_PlAYer if you prefer!)
  40.  
  41.     The header
  42.     ╣╣╣╣╣╣╣╣╣╣
  43.     Starts on the second line (or after some comments lines) and gives
  44. general infos on the slideshow:
  45.  
  46.     w=xxxx    the width of the movie
  47.     h=xxxx    the height of the movie
  48.     c=xxxx    the compression (the type of file):
  49.             tga2 for TGA 2 uncompressed (24 or 16 bits)
  50.             ximg for IMG with 'XIMG' extension and 256 colors
  51.             gif8 for either gif87a or gif89a
  52.     b=xxxx    size of the buffer to load the entire largest image file
  53.  
  54.     Those first 4 infos can't be ommited! The following can (for a
  55. slide show, but must appear for a MOVIE-create):
  56.  
  57.     t=xxxx    time for one frame (number of 1/200sec), with a GIF it is
  58.         the time to wait between two frames (without the display
  59.         time), with 0, no delay block will be added.
  60.     f=xxxx    number of frames in the whole slideshow
  61.     o=file_path    path and name of the file to create (MOV, RLE16,
  62.             RLE8 or GIF compression)
  63.     s=file_path    path and name of the sound file to add to the MOV
  64.             (WAV or AVR, 8/16 bits, mono/stereo)
  65.             * not used with GIF movies *
  66.  
  67.     If 's=' is present, then 't=' is ignored and the frame rate is
  68. computed according to the sound duration.
  69.  
  70.     q=x    quality, default value is 5 (5 bits per color), but you
  71.         can reduce it to 4,3,2 or even 1 to get a more efficient
  72.         compression, but with a lost of quality. I've tried 'q=2'
  73.         on some frames, it seems to be correct (better
  74.         compression, good quality). 'q=' is only useful when a MOV
  75.         is created, it fixes the number of signifiant bits to know
  76.         if the color of a pixel has changed or not.
  77.         * not used with GIF movies *
  78.     k=xxxx    specifies the rate of the key frames (for example, with
  79.         k=5, frames #5, 10, 15, 20 ... will be key frames). See
  80.         below: "Key frames use".
  81.         * not used with GIF movies *
  82.     r=xxxx    for GIF files only, fixes the number of loops for that
  83.         movie, the range is 0 to 65535. This will add the NETSCAPE
  84.         extension as follows:
  85.         $21, $ff, $0b, 'NETSCAPE', '2.0', $03, $01, Intel word=xxxx,
  86.         $00.
  87.         A value of 0 indicated an infinite loop.
  88.  
  89.     The order of those infos is not fixed, but you musn't put spaces
  90. between the characters (w = 320 is wrong!).
  91.  
  92.     The datas
  93.     ╣╣╣╣╣╣╣╣╣
  94.     Starts immediately after the header with a key word:
  95.     data
  96.  
  97.     Then, every line is read and:
  98.     if starting with a '.' --> it's a command, executes it
  99.     else               --> it's the name of a file, displays it,
  100.                    and its name becomes the current name.
  101.  
  102.     commands are:
  103.     .rept xxxx
  104.     .endr
  105.         repeat xxxx times what's between rept and endr. Loops can
  106.         be nested.
  107.  
  108.     .disp
  109.         displays the file corresponding to the current name
  110.     .getp
  111.         uses the palette of the next file (only applied with
  112.         palette based images). If '.getp' is not specified, then
  113.         the palette will be ignored (for example when all of the
  114.         frames share the same palette that is loaded once), this
  115.         speeds up the display when running in NOVA 256c (because
  116.         the palette must be passsed to the VDI).
  117.         * not used with GIF movies *
  118.     .incr
  119.         increments a number found into the current name (example,
  120.         if name was: C:\IMAGES\FRM00001.TGA it becomes
  121.                  C:\IMAGES\FMR00002.TGA)
  122.     .decr
  123.         same as above with a decrementation.
  124.     .stop
  125.         end of the slideshow. This command MUST appear, else the
  126.         program crashes.
  127.     .keyf
  128.         forces the next frame to be a key-frame (if k=xxxx is
  129.         used, then this auto key counter will be reset). See below
  130.         at "Key frames use".
  131.         * not used with GIF movies *
  132.  
  133. GIF movies
  134. ╣╣╣╣╣╣╣╣╣╣
  135.     A GIF movie can only be created from GIF images, those images must
  136. have the same global size and the same global palette (if a local palette
  137. is present, it will be stored).
  138.     Every other bloc than $2C (the images) are skipped (for example
  139. copyrights, infos, etc...). Only one bloc is always added, the one defined
  140. by myself that indicates the number of frames:
  141.     $21, $ff, $0b, 'M_PLAYER', 'FRM', $04, Intel Long Frames, $00
  142.  
  143.     This bloc must be located just after the local palette (and, if
  144. present, after the Netscape extension concerning the looping).
  145.  
  146.     The delay time between two frames is stored into an unsigned word,
  147. so it is limited to 65535, this means no more than 655.35 seconds (and so
  148. 131070 for 't=' as it a number of 1/200 of second). If the value is
  149. greater than this limit, 0 will be used instead (meaning no delay!).
  150.  
  151.     M_Player can be used to modify an existing GIF-Animation (for
  152. example to add the M_PLAYER extension, the Netscape extension or to modify
  153. the delays between two frames,...).
  154.     Example, I have an animation NUKE01.GIF that has no M_Player
  155. extension, with a infinite loop and that is played too fast, I run it once
  156. to get the infos:
  157.     size 64x64, 9 frames displayed (in the stats box at the end. When
  158. an anim has a loop, SHIFT stops it!).
  159.     Then I create the following batch file:
  160.  
  161. m_pLaYeR
  162. w=64            the size I noted
  163. h=64
  164. c=gif8
  165. b=16000               the file is only 15xxx bytes long
  166. t=11                 11/200 = 0,055s of delay
  167. f=9                   9 frames into my initial anim
  168. r=3                  will repeat only 3 times (instead of infinite)
  169. o=C:\TGA\nuke.GIF     the output file
  170. data
  171. C:\TGA\nuke01.GIF       only one file!
  172. .stop
  173.  
  174.     Upon exit, I'll have a new anim NUKE.GIF with the M_PLAYER
  175. extension, with different delays and with 3 loops only. The output file is
  176. shorter, because M_Player has skipped very info bloc!
  177.  
  178.  
  179. Example of a BATCH FILE:
  180. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  181.     (The comments starting with ** don't appear in the file!)
  182.  
  183. ** start of file
  184. M_Player                        ** Id
  185. ; comes from a FLI            ** comment
  186. w=320                           ** width
  187. h=200                ** height
  188. ; 67/200 means 3 f/s        ** comment
  189. t=67                ** time for one frame
  190. f=29                ** number of frames
  191. c=tga2                ** files are TGA 2 uncompressed
  192. b=192018            ** size of one file (320x200x3 + 18)
  193. data                ** end of header/start of data
  194. E:\imprimer\mou00001.tga    ** first frame, display it
  195. .rept 2                ** twice the whole
  196.   .rept 7            ** 7 times
  197.     .incr            ** increment name of file (00002 to 00008)
  198.     .disp            ** and display it
  199.   .endr                ** loop
  200.   .rept 7            ** another 7 times
  201.     .decr            ** dec name of file (00007 to 00001)
  202.     .disp            ** and display it
  203.   .endr                ** loop
  204. .endr                ** twice!
  205. .stop                ** end of slideshow
  206.  
  207.  
  208.     Well, this example has displayed:
  209.     mou00001.tga
  210.     mou00002.tga
  211.     ...
  212.     mou00007.tga
  213.     mou00008.tga
  214.     mou00007.tga
  215.     ...
  216.     mou00001.tga
  217.     And this twice! The images came from a FLI that I saved using the
  218. Step by Step mode.
  219.  
  220.     INCR and DECR commands can only work correctly if the names of the
  221. files END with digits! (for example 00001BB.TGA won't work because it
  222. ends with BB).
  223.  
  224. Another example:
  225. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  226.     You can specify each file if you don't want to use commands:
  227.  
  228. M_PLAYER
  229. w=184
  230. h=240
  231. b=50000
  232. c=ximg                ** t= ommited because there's a sound
  233. f=5
  234. o=C:\ANIM\US.MOV        ** will create a MOV if Alt+GO
  235. s=C:\SOUNDS\KISS.AVR        ** will add this sound if Alt+GO
  236. data
  237. .getp                ** supposing that all have the same
  238. C:\IMAGES\I.IMG        ** palette, we load it once!
  239. C:\IMAGES\YOU.IMG
  240. C:\IMAGES\I.IMG
  241. C:\IMAGES\YOU.IMG
  242. C:\IMAGES\YOU_N_I.IMG
  243. .stop
  244.  
  245.     '.stop' is the only command that must appear.
  246.  
  247.  
  248. Common errors (those I made...)
  249. ╣╣╣╣╣╣╣╣╣╣╣╣╣
  250.     * The header is built BEFORE adding the frames, so the number of
  251. frames that you specify (f=xxxx) must be exact! Else you'll get a totally
  252. corrupted MOV file. To ensure that it's the right value, launch a
  253. slide-show before encoding, if total_frames=frames_displayed, it's Ok.
  254.     * this is the same for 'w=' and 'h='. Be sure that all of the
  255. images have the same size, the one you specified.
  256.     * the 'supported' message into the graphic box is based upon your
  257. 'c=xxxx'. The program hasn't read a file to verify that, ensure that it's
  258. the good fromat.
  259.     * The sound frequencies accepted are those from the PC world:
  260. 11025, 22050 and 44100 KHz, or the closest possible to them. Else, you get
  261. an 'Unsupported' message in the sound box.
  262.     * if using IMG images you get the RLE8 compression that uses a
  263. palette. But, the MOV can contain only ONE palette, so you must be sure
  264. that all the images share the same colors, else, it's the last palette
  265. read (with .getp) that will be saved.
  266.  
  267. Key-Frames use
  268. ╣╣╣╣╣╣╣╣╣╣╣╣╣╣
  269.  
  270.     Here is a brief introduction to the utility of inserting
  271. key-frames into a movie. There are two cases:
  272.     - your machine is fast and no frame will be skipped when playing,
  273.     then you don't need to use the key frames.
  274.     - your machine isn't so fast and there may be some frames skipped,
  275.     the use of key-frames is highly recommended!
  276.  
  277.     What happens when a frame is skipped?
  278.  
  279.     In order to increase the compression, only the differencies
  280. between two frames are stored, this means that one frame is only a partial
  281. display. If one frame is skipped (because of the synchronisation) the next
  282. one won't have the background expected! You'll get a wrong display.
  283.  
  284.     A key frame is used to solve this problem, it is a complete
  285. reconstruction of the screen. So, when a frame is skipped, M_PLAYER just
  286. has to wait for the next key-frame to go on displaying.
  287.  
  288.     An example:
  289.  
  290.     Suppose you have used k=5 and t=40 (5 frames per second) into the
  291. header and that your machine can only display 3 images /second. Here is
  292. what will happen:
  293.  
  294.     second #1: frames 1,2,3
  295.     second #2: frames 5,6,7
  296.     second #3: frames 10,11,12
  297.     etc...
  298.  
  299.     Every key frame will be at its exact position (in time), and
  300. between 2 key-frames, the player does as much as it can. If you play this
  301. same movie with a faster machine, you'll get maybe:
  302.     second #1: frames 1,2,3,4
  303.     second #2: frames 5,6,7,8
  304.     second #3: frames 10,11,12,13
  305.     etc...
  306.     And with a very fast machine, you'll get every frame.
  307.  
  308.     The best is to put 2 key-frames per second, this way, the display
  309. will be synchro with the sound twice a second.
  310.  
  311.     You must know that a key frame is larger than a normal one,
  312. because it rebuilds every pixel, and that inserting too few key-frames
  313. will lead to a poor synchro quality. It's a question of balance. Make some
  314. tests to find the best solution.
  315.  
  316.     Idea: it's a good idea to choose the frames where the background
  317. changes suddenly, because anyway most of the pixels will be rebuilt!